This sample accompanies chapter 7 of the book "Embedded Controller - Grundlagen und praktische Umsetzung fr industrielle Anwendungen" by Ruediger R. Asche (Springer Vieweg 2016, ISBN 978-3-658-14849-2). Please refer to the discussion in the book (chapter 7 as well as Appendix 1) for a discussion of what the sample does, how it does it and how to utilize it.

The sample was written for the NXP Kinetis FRDM64K evaluation board. It was compiled under iSystem's WinIdea 9.12.256 and tested using the iTAG50 debug probe. The network connection behavior was tested against an Atmel sam v71 xplained ultra evaluation board running a modified version of this software.

What the sample does
--------------------


The NXP Kinetis FRDM64K evaluation board has an accelerometer on board. The sample uses one task to periodically read the accelerometer and record deltas against the last reading. Using the LOCAL_PROCESSING preprocessor directive, the deltas are visualized on the local multicolor LED on board the evaluation board, bypassing the real purpose of the sample (this is for test purposes).

The sample demonstrates communication betwenn the controller and a host. The aforementioned accelerometer deltas are packed up in user telegrams and dispatched over the network. The sample demonstrates how to implement a protocol driver.

In WinIdea's Settings/Compiler/Command Line defines Dialog, either RUN_AS_SERVER,RUN_AS_CLIENT or SIMULATE_LOOPBACK can be defined. If one of the former two are defined, the controller running the sample must be associated with network credentials to allow for successful connection establishment. This happens via the constants CP_USERDEFINEDTCPPORT, CP_USERDEFINEDREMOTETCPADDRESS, CP_USERDEFINEDLOCALTCPADDRESS,  CP_USERDEFINEDLOCALTCPNETMASK and CP_USERDEFINEDLOCALTCPGATEWAY that should be adapted to the local network settings. If SIMULATE_LOOPBACK is defined, the sample can be run on a single machine, bypassing the physical ethernet and routing all packets via the local IPv4 loopback address 127.0.0.1. With SIMULATE_LOOPBACK active, the sample also terminates and re-establishes local connections in random intervals ranging up to a minute - this is to demonstrate the robustness of the protocol implementation against connection problems.

With SIMULATE_LOOPBACK active, the accelerometer delta changes are routed back to the same evaluation board, again visualizing the changes on the multi color LED. 

The preprocessor directive STRESS_TEST in spirit_level.c can be used to generate a constant application load on the controller.

A word of caution: Bugs in physical ethernet drivers are very common. In particular, many drivers are not tested under heavy network loads. SIMULATE_LOOPBACK can be employed to test the basic functionality of the network protocol on a given target as well as the logical functionality of the middleware network stack. If your application passes the SIMULATE_LOOPBACK regress test but does not pass a regress test of two controllers (or one controller and a host), this is a fairly reliable hint that 1. the protocol implementation as well the network middleware are robust and 2. there is some problem in the physical network driver.

The sample suite demonstrates several aspects of embedded controller design discussed in the book mentioned above, for example message pumps, FSMs, high level timeouts and tips and tricks for protocol design and implementation. You may also wish to experiment with watchdog retriggering in either the receiver task or the comm loop tasks (all of those are implemented as non blocking). You may also want to look into possibilities to collate a comm loop task and its corresponding receiver task into a single task to save stack and TCB footprint.

Please observe the disclaimers in all file headers. I do welcome all reports on problems and comments on the code but can not provide support for any of the application suites.

Ruediger R. Asche, Oct. 2016  
  